Tech Arsenal 1/Tech Arsenal (Arsenal Computer).ISO/tek-20/tcp90136.zip/TCP90136.TXT

Text File | 1990-09-14 | 8KB | 204 lines

Path: tosspot!indep1!pete
From: [e-mail] (Peter Franks)
Newsgroups: to.tosspot
Subject: TCP Digest #136
Message-ID: <[e-mail]>
Date: 14 Sep 90 01:27:13 GMT
Reply-To: [e-mail] (Peter Franks)
Followup-To: to.tosspot
Distribution: to
Organization: as little as possible
Lines: 191

TCP-Group Digest            Wed, 12 Sep 90       Volume 90 : Issue 136

Today's Topics:
             Ethernet mysteriously quit working (2 msgs)
                              Mailbox ID
                  multispeed fdx repeater? (2 msgs)
                         SSIDs and NETROM IDs
                        why the H in [NET-H$]

Send Replies or notes for publication to: <[e-mail]>
Send requests of an administrative nature (addition to, deletion from the
distribution list, et al) to: <[e-mail]>

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
----------------------------------------------------------------------

Date: Tue, 11 Sep 90 14:28:51 CDT
From: Jay Maynard <[e-mail]>
Subject: Ethernet mysteriously quit working
To: [e-mail]

Gerry, N5JXS' NOS quit working on his office Ethernet a couple of days ago.
Over the weekend, the routers connecting his network to the outsied world were
powered off and back on, and possibly reconfigured. Unfortunately, he can't do
anything on his local LAN either. He's running an NE1000  and the Clarkson V7
packet driver, and NOS 900828. He sees traffic on the lan (as verified by a
'trace et0 0x111' command), but never transmits. Any ideas?

------------------------------

Date: Wed, 12 Sep 90 04:14:38 UTC
From: [e-mail] (Phil Karn)
Subject: Ethernet mysteriously quit working
To: [e-mail], [e-mail]

Jay,

When NOS stops transmitting, one of the first things to check is buffer
memory exhaustion (either caused by a memory leak bug or by simply not
having enough memory).  Do a "mem stat" and see if the failure counts
are increasing.

Of course, rebooting the system should get it working again. If this
DOESN'T do it, then something else is wrong -- perhaps his network's IP
addresses were changed?


Phil

------------------------------

Date: Tue, 11 Sep 90 09:37:09 EDT
From: [e-mail] (D. Crompton)
Subject: Mailbox ID
To: rutgers!wb3ffv.ampr.org![e-mail], [e-mail]

The  'H' in [NET-H$] stands for hiarchical (sp) forwarding. This tells
the mailer the capabilities of the distant bbs. IF it is not there the
sending bbs assumes the receiving bbs does not have this capability.
Since TCP does have this capability it should be there.

Doug

------------------------------

Date: Tue, 11 Sep 90 08:44:14 -0700
From: brian (Brian Kantor)
Subject: multispeed fdx repeater?
To: tcp-group

I've put together a full-duplex two meter packet repeater that
regenerates the FSK tones by the simple expedient of hooking a TNC's
demodulator to its modulator.  That works really well for 1200 bps
but for all practical purposes, is limited to that speed.

I'd like to encourage the growth of other speeds, primarily 9600 bps,
and I think having the repeater capable of that speed would be a boost.
I don't want to put up a repeater that is 9600 bps only, because it
would receive little use and simplex 1200 bps would probably continue to
occupy its input and outputs.

I've come up with two schemes for multi-speeding the repeater:

1) have another modulator/demodulator hooked in, such as a hacked K9NG
or G3RUH modem, and OR the 1200 and 9600 bps DCDs into PTT, and use each
one to gate the audio from the respective modulator into the transmitter.

2) simply make the audio passband between receiver and transmitter flat
and linear over 30Hz to 15kHz or thereabouts, so that it would be
able to repeat either the AFSK 1200 bps stuff OR the direct-FSK output
from the K9NG modems.  I'm not sure what I'd do to key the transmitter
- a simple noise squelch is out because I don't want people talking
through the thing.

I can do either, I think.  The receiver is that wide, and the
transmitter is a direct-FM widget, so it ought to be possible to do #2,
which I'm leaning towards because it's cheaper.

Suggestions?  Anyone tried anything like this?
    - Brian

------------------------------

Date: Tue, 11 Sep 90 12:13:56 PDT
From: Brian Lloyd <[e-mail]>
Subject: multispeed fdx repeater?
To: [e-mail]

I built a packet repeater that had a very flat audio passband (you
can't get flat out to 15 kHz without a lot of extra bandwidth in the
receiver) and the transmitter was keyed by the DCD output of a real
Bell 202T modem (it did not false on voice at all).  The plan was to
add an FSK demodulator to generate DCD for 9600 bps FSK and then OR
the two carrier detect circuits to generate a key-down voltage but we
didn't get it completed.  The plan should work tho' and it should be
fairly inexpensive.

BTW, I don't think that you need a transmitter with an FM modulator.
It seems to work just as well to have a PM modulator with the correct
preemphasis.

73 de Brian, WB6RQN

------------------------------

Date: Tue, 11 Sep 90 8:49:10 MST
From: [e-mail] (Dave Fritsche)
Subject: SSIDs and NETROM IDs
To: [e-mail] (tcp-group)

>This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling
>can be done by a simple C routine, and might even be built into the netrom
>commands in NOS. I know there's been a similar scheme mentioned on
>Compu$erve, but that one (using the hex representation of the low 16 bits)
>would break down at the edges of the assignment areas.

What we are all using here in Arizona and New Mexico, is something that
sounds similar to the Compuserve method.  Instead of just the lower
16 bits though, we convert the lower 24 bits to hex and just use that
as the NETROM node ID.  I don't see any good reason to include the "#"
in the node ID.  In fact, with some versions of "The Net", IDs that
begin with a "#", don't get rebroadcast.  Some people here were using
IDs with the "#" and couldn't figure out why they had such a high
quality at a node, but weren't being passed on to the next one.  Once
they simply dropped the "#", everything worked as expected.

The string of HEX digits as an ID is certainly unique.  You can then
also "pick out" the TCP/IP nodes at a glance, instead of having to search
for "IP" or "TCP" burried in the sea of alphabet soup.  It also allows
someone else that has spotted your ID on the air, to go ahead and add
the IP address to their "domain" table, or hosts.net file.  If some of
the folk that like to go spelunking around thru NETROM routes comes
upon your node, who knows, maybe they'll like what they see and get
involved in TCP/IP :-).  Certainly, once they hit a node with an ID like
that, they'll know from then on what to expect if they connect.

Dave Fritsche (wb8zxu)
[e-mail]

------------------------------

Date: Tue, 11 Sep 90 13:34:29 GMT
From: toth!dave (David B. Toth)
Subject: why the H in [NET-H$]
To: [e-mail]

In response to Howard Leadmon's question, the H identifies that the
receiving station is prepared to handle hierarchical addressing in the
@BBS field ... it oddoes not have to guarantee that it understands them,
but only that it will accept it without barfing and presumably pass it
on ...
ex   SP W3IWI @ W3IWI.MD.USA
would be passed if the H was there; otherwise only
     SP W3IWI @ W3IWI
would be passed if the exchange was
[NET-$]

73, Dave VE3GYQ
ria.ccs.uwo.ca!toth!dave

------------------------------

End of TCP-Group Digest
******************************

--
+------------------------------------------------------------------------------+
|  Peter Franks  |          [e-mail]  OR  [e-mail]          |
|      NI9D      |                   Use whichever one works                   |
+------------------------------------------------------------------------------+